It logs in, does the work, and shows you what changed.
A run is one workflow, described once and performed on a cadence. Anvil connects to your systems through their own APIs, applies the rules your team already follows, and stops at the approval you nominate.
Read · Decide · Execute
It reads the record, not a copy.
Anvil answers from live data in your system of record. No nightly extract, no warehouse replica that was correct at midnight, no reporting layer that lost the exceptions on the way through.
- Reads through each system's own API, with a scoped service account
- No warehouse copy, no nightly extract, no stale balance
- Entity structure, approval matrix and thresholds read from the source
- Every read is logged against the run that asked for it
Connection
Per run
- Connection
- Native API, OAuth service account
- Scope
- Declared per run, enforced per call
- Latency
- Live record, not a replica
- Residency
- Your tenant, your region
It decides against your rules.
Your close checklist, your approval matrix, your materiality thresholds — written down, versioned and readable by the people who own them. Anything the rules do not cover becomes an exception with its reasoning attached.
- Your close checklist, approval matrix and materiality thresholds
- Rules are versioned; the ledger records which version ran
- Anything outside them becomes an exception with its reasoning
- No silent judgement calls on materiality or policy
Judgement
Versioned
- Rules
- Yours, versioned, human-readable
- Exceptions
- Named owner, evidence attached
- Model
- Swappable; the ledger is not
- Drift
- Flagged when inputs stop matching the rule
It writes, and you can undo it.
Execution is the point, so it is the part with the most constraints: batched writes, thirty days of reversibility, one screen of approval, and a ledger entry that names the rule, the inputs and the human.
- Writes are posted as reversible batches, never row by row
- A named human holds the last step on anything material
- Approval is one screen: the diff, the rule, the exception
- Every write is attributable to a run, a rule and an approver
Execution
Reversible
- Writes
- Batched and reversible for 30 days
- Approval
- Named human, single screen
- Audit
- Append-only ledger, exportable
- Rollback
- By batch, from the ledger
The questions procurement asks.
Where does it run?
Inside your tenant, in your region. Anvil connects out to your systems through their own APIs with a scoped service account; nothing about your records is copied into a warehouse of ours.
What happens when it gets something wrong?
Writes are posted as batches and reversed as batches, for thirty days. The ledger records the rule version, the inputs and the approver, so the reversal is a decision rather than an investigation.
Does it need us to change our ERP?
No. Anvil operates the system you have, using the configuration you have. If a process only exists in someone's head, that is the week of work — writing it down, not migrating anything.
Who approves the work?
A named person you nominate per run. Approval is a single screen: the diff, the rule that produced it, and any exception. If approving takes longer than doing the task by hand, we have built it wrong.
How is it priced?
Per run, per month. A run is one workflow live in your tenant, with unlimited people watching it. Seats are free because watching the ledger should never cost anything.
What do the auditors get?
An exportable, append-only record of every read, decision, write and approval, with timestamps taken from your systems rather than from an email thread.
Book a demo
Bring one process you dread. We will run it against a sandbox copy of your tenant and show you the ledger.
Read the work
Five runs written by the engineers who implemented these systems, with the numbers they actually moved.